Release 10.1A: OpenEdge Getting Started:
Application and Integration Services

Connection process

To establish a physical connection:

Directly to an AppServer without a NameServer — A non-Web service client must know the network location (host and port number) of an available AppServer instance to which it can connect. A Web service client invokes a special method that binds the client session to the appropriate Web service deployed to the WSA. This deployed Web service is configured to directly access a specific AppServer that provides the required application service. A non-Web service client or a Web service deployed to the WSA can also make this connection using Secure Sockets Layer (SSL) tunneling in order to secure the connection over an intranet.
Directly to an AppServer using the NameServer — A non-Web service client must know the application service that it needs to access and the network location (host and port number) of the controlling NameServer of an available AppServer instance to which it can connect that has registered with the NameServer to support the specified application service. A Web service client invokes a special method that binds the client session to the appropriate Web service deployed to the WSA. This deployed Web service is configured to access the controlling NameServer that provides the physical AppServer connection required to access the application service. A non-Web service client or a Web service deployed to the WSA can also make this connection using SSL tunneling in order to secure the connection over an intranet.
Over the Internet using the AppServer Internet Adapter (AIA) — A non-Web service client must know the HTTP/S URL to the AIA to access an AppServer directly, or it must know this same URL and the required application service to access an AppServer using a controlling NameServer. In any case, the AIA makes the AppServer connection according to how it is configured in OpenEdge.

To establish a logical connection:

Direct to an available AppServer in the session-free connection pool — A non-Web service client must know the application service to which it needs to connect and the network location (host and port number) of the controlling NameServer for all AppServer instances that have registered with the NameServer to support the specified application service. A Web service client invokes a special method that binds the client session to the appropriate Web service deployed to the WSA. This deployed Web service is configured to access the appropriate controlling NameServer for all AppServer instances that support the application service. A non-Web service client or a Web service deployed to the WSA can also make the physical AppServer connection using SSL tunneling in order to secure the connection over an intranet.
Over the Internet using the AppServer Internet Adapter (AIA) — A non-Web service client must know the application service to which it needs to connect and the HTTP/S URL to the AIA running on a Web server. In any case, the AIA makes each physical connection to an AppServer from the session-free connection pool according to how it is configured in OpenEdge.

The client application requires no other knowledge about the AppServer to which it connects except the published API (the entry points and prototypes) required to access the AppServer’s remote procedures. You provide this API to client programmers based on your AppServer application and the type of client they are programming.

For HTTPS (over the Internet) or SSL (over the intranet) connections, the client, Web server (for Internet connections), and AppServer (for intranet connections) must have appropriate keys and digital certificates installed in order to authenticate and encrypt communications across these connections. For more information, see OpenEdge Getting Started: Core Business Services .